Growth in demand for WLANs is driving the development of new technology to provide higher throughput. To a greater extent this growth is due to the increased number of users and applications desiring wireless transmission and to a lesser extent to the emergence of new applications needing higher transmission rates along a single connection between two points. The former requires higher aggregate throughput. The latter requires increased link throughput. This paper deals with a MAC based approach for increasing aggregate throughput of a wireless network (i.e. a WLAN or a wireless network) by enabling the simultaneous transmission on multiple channels.
The MAC protocol distinguishes between two logical channel functions, the Control Channel (CC) and the Data Channel (DC). Stations exchange control and management frames on the control channel. The data channels carry data traffic. Reservations for transmission on the various data channels are made by exchanging control frames on the control channel. This control channel is used by each node for time reservations on data channel(s) and for acknowledgements. The control channel does not change dynamically (fast).
Data channel(s) are the channels used by nodes to transmit data traffic. Each node may transmit always on the same data channel(s), or it may select a channel to transmit on demand (dynamic channel assignment).
As extensions of the legacy RTS and CTS messages, the CC-RTS and CC-CTS are used to reserve a data channel for the time it takes to transmit a Transmission Opportunity (TXOP). A TXOP (transmit opportunity) is a sequence of frames transmitted between a pair of nodes following a single contention for the channel. A Source node is the node initiating the TXOP, and the Destination node is the node receiving the TXOP. Data traffic can be transmitted only on a data channel that is idle. The particular data channel selected for transmission of the TXOP is indicated in a special field on the CC-RTS/CC-CTS.
A CC-RTS frame is the frame used by a node initiating a TXOP. A CC-CTS frame is used by a node accepting a TXOP. If acknowledgement of receipt of transmission is desired, it can be sent either on the data channel or on the control channel. An acknowledgement on the control channel, known as the CC-ACK, identifies the individual frame in a sequence of frames that were received successfully (similar to 802.11e Group Ack).
A node with frames to transmit to a neighbor sets its data radio to transmit on a permissible data channel, sends a CC-RTS on the control channel to the destination node, and waits for a CC-CTS, which contains the acceptance or denial of the channel reservation request for the selected/assigned data channel.
If the destination node receives the CC-RTS, it sends a CC-CTS. The CC-CTS will contain a zero in the Reservation Duration field if the destination node does not accept the reservation request in the CC-RTS. A CC-CTS is not sent if the Reservation Duration field or the Number of Frames field contains a zero in the CC-RTS.
If the destination node accepts the reservation request in the CC-RTS, the destination node sets a data radio to receive on the data channel assigned/selected by the source node. If the destination node receives the same CC-RTS in the SIFS plus tx time, it sends another CC-CTS and waits for a time interval equal to SIFS plus CC-CTS tx duration. If the CC-CTS has not arrived at the source node by the expiration of SIFS plus CC-RTS tx duration plus CC-CTS tx duration, it transmits within SIFS another CC-RTS on the control channel.
If the CC-CTS is received within a time interval comprising the SIFS plus the CC-RTS tx duration plus the CC-CTS tx duration by the source node, and the Reservation Duration field has a zero value, the source node sends a CC-RTS to the destination node with the Reservation Duration field set to zero. If the CC-CTS is received within a time interval equal to the SIFS plus the CC-RTS tx duration plus the CC-CTS tx duration by the source node, and the Reservation Duration field has been changed to a longer value, the source node sends a CC-RTS to the destination node with the Number of frames set to zero. If the CC-CTS has arrived within the time interval equal to the SIFS plus the CC-RTS tx duration plus the CC-CTS tx duration at the source node, and the Reservation Duration field has a non-zero value, the source node transmits the frame(s) in the TXOP.
Data can be transmitted only if the selected data channel is idle. The reservation process may start before the data channel becomes idle. Contention for the control channel and the transmission of a CC-RTS and CC-CTS can take place while the data channel is still busy. Traffic prioritization is more effective if data channel reservations are made right before the data channel becomes idle, as described in co-pending application Ser. No. 11/408,695 filed on Apr. 21, 2006 titled “Prioritized Access in a Multi-Channel MAC Protocol”, the disclosure of which is incorporated by reference in it's entirety.
The CC-RTS/CC-CTS exchange may be defined so that it can reserve multiple data channels, or the control channel and one or more data channels, for the same time interval. The CCC protocol can be expanded to allow for several channels to be reserved at once for the communication between two nodes. For instance, the sending node may reserve a data channel and the control channel for the transmission data. The data may be split into two streams to be transmitted simultaneously to the destination node one two independent radios. This would double the data rate between two nodes. In this scenario, the node needs two radios. Alternatively, two data channels may be reserved at once by the transmitting node. The two channels may be adjacent and a single broader bandwidth radio would be used to transmit and receive. If the two channels are not adjacent, two independent data radios would each transmit a portion of the data.
Two multi-channel MAC protocols are examined. One protocol requires at least two radios per device: one radio, the ‘control radio’ is dedicated to the control channel, and the remaining radios, called ‘data radios’, are tuned to data channels. Whereas the control radio may be used for control and data traffic, only data traffic may be sent through the data radio(s). We refer to this protocol as the ‘multi-radio protocol’. The nodes in a wireless network employing a multi-radio protocol are referred to as ‘multi-radio nodes’.
The second protocol does not require a node to have a dedicated control radio. The same radio is switched between control and data channels. The nodes in a wireless network employing a single-radio protocol are referred to as ‘single-radio nodes’.
When both single-radio and multi-radio nodes comprise a wireless network, referred to as a ‘mixed network’, additional measures are taken to allow for the co-existence of the two types of nodes.
With the multi-radio protocol, each node maintains a channel-specific NAV to avoid collisions. The NAV tracks the length of time for which a control or data channel is reserved. The NAV is the time period the node must refrain from transmitting on the channel, and is updated when a node receives a reservation request or a response to the reservation request. The NAV of a data channel is based on the value of the Reservation Duration field of the CC-RTS/CC-CTS. NAV-setting frames received on the data channels also update the data channel NAVs.
With a single-radio protocol, it is not possible to maintain NAV solely based on the NAV setting frames received on the control and data channels because there is no dedicated radio on the control channel. To make up for the lost NAV information, requirements to release all channels periodically force the NAV of all channels (either implicitly or explicitly) to be reset to zero. For the same reason, the control channel and any data channels shared by both single-radio and multi-radio nodes must be released periodically in a mixed network.
In a mixed network, multi-radio and single-radio nodes must co-exist in a way that enables both types of nodes to access channels.